The NVM Express (NVMe) specification defines a command set for PCIe-based Solid-State Drives (PCIe SSDs). It is a host/device architecture, where the hosts are the CPU cores of a server, and the device is a PCIe SSD. A standard NVMe driver is available on the host side for different operating system platforms (Linux, Windows . . . ). On the device side, the NVMe specification must be implemented in an SSD controller, where it could be a hardware or a software architecture.
An NVMe is a submission/completion queue-based protocol. The commands are created by a host device and placed in a submission queue. When a command is ready in the submission queue, the host device indicates the readiness to a connected device through a submission queue tail doorbell register update. The connected device then fetches the submission command from the host memory and executes the submission command according to its priority defined with an arbitration scheme.
An NVMe host controller provides an optimized command submission and completion path in which there may be no guaranteed order of execution and completion of NVMe commands. Alongside, support has been added for many advanced features like Namespace management, Single Root I/O virtualization (SR-IOV), Reservations etc. in the NVMe standards. For example, consider the following NVM subsystem as shown in FIG. 1 with a multi-port 102, a multi-path I/O 104, namespace sharing 106 and SR-IOV 108 support. The firmware running on such a multi-port/multi-function SSD device is expected to handle any and all incoming commands from one or more of the interfaces (Admin or I/O queues) of the virtual functions assigned to the NVMe controller, which may externally be connected to different hosts.
Many standard protocols, like the NVMe, have a set of administrative or configuration commands that configure the behavior of a device or controller, subject to the guidelines drawn by the protocol. For example, a few of the NVMe configuration commands include those for deletion of a submission queue, access permissions of a namespace via reservations, access control of a namespace via namespace management/attachment, and re-formatting a namespace with different namespace attributes like a Logical Block Address (LBA) size, protection information, aborting a previously sent command etc.
However, in an NVMe environment where parallel processing of commands is involved, these NVMe configuration commands have dependencies on other commands being executed inside the device. Here parallel processing or parallelism in NVMe environment refers to execution of one or more commands simultaneously by a multi-core processor.
The NVMe specification is unprecedented in its architecture for not enforcing an order of execution or completion of commands. Thus, in the NVMe realm, the problem of command interdependencies is considerably new to device designers and firmware developers. While in single-function-single-host devices, the dependencies will be of a lesser degree, as a single ideal host can manage to resolve the explained command conflicts cleanly. However, this is not true for a multiport-multifunction device.
FIG. 2 illustrates an NVMe environment where the host is managing the command dependencies, rather than the device. In this scenario, as well, problems arise such that the environment cannot work for a multi host scenario, as the device health will not be monitored by the host, and uncooperative hosts remains an issue. The NVMe specification is unprecedented in its architecture of not enforcing order of execution or completion of commands. Thus, in the NVMe realm, the problem of command interdependencies is considerably new to device designers and firmware developers. While in single-function-single-host devices, the dependencies will be of a lesser degree as a single good host can manage to avoid resolving the explained command conflicts cleanly as shown in FIG. 2. However, this is not true for a multi-function-multi-host device.
FIG. 3 is a schematic diagram illustrating a method of managing dependencies by a hypervisor, according to a related art. The command interdependencies may be resolved by a hypervisor layer that is introduced between the host and the drive as shown in FIG. 3. The hypervisor layer 302 is adapted to allocate hardware resources of the host device 308 to one or more virtual machines in real-time. However, such a solution also exhibits issues, such as unnecessary complexity in the system, increased overhead/synchronization and the like.
In view of the foregoing, there is a need for a method for resolving command interdependencies in a non-volatile memory express (NVMe) multiport-multifunction environment.